Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

SmartDataObject basics

This section reviews some of the basic characteristics of the SmartDataObject. You can create SDOs either by running a wizard in the AppBuilder or by running the Progress Dynamics Object Generator. Generally this section presumes that you have created SDOs initially using the Object Generator, although you can then edit and customize them in the AppBuilder.

The Object Generator creates an SDO for each table, with a database query selecting all the rows in that table. Customizing the SDO in the AppBuilder allows you to modify the query, which might involve a join of two or more tables, along with a specific list of fields from those tables to be used in the SDO. You can modify names and characteristics of these fields (such as format) in the SDO. You can define additional calculated fields to store values not directly represented by single database fields.

Note: Properties of calculated fields in static SDOs are stored in the include file, not in the Repository.

This field list is turned into a Progress temp-table definition whose name is RowObject. At run time, records are read out of the database tables into the RowObject temp-table. All other client-side objects (viewers and browsers and the like) access the values in this temp-table rather than reading and writing database records directly.

There are two primary reasons for using this temp-table as an intermediary for data access:

It allows you a degree of freedom in defining SDOs whose definitions are not tied directly to a particular database table definition. This means that if you change data definitions at a later time, you do not necessarily have to change application components to match them. You can rename fields between the database and the temp-table, and the SDO support code automatically makes sure that values are transferred properly between the database field and the temp-table field (and back again if you change the value). Fields in the database tables that are not needed or wanted in the application can be left out of the SDO definition. The SDO lets you mask joins between tables by presenting the join as a single logical table in the SDO.
SDOs are designed to support distributed applications. The OpenEdge AppServer allows greatly increased efficiency of data access compared with client/server in many cases. In particular, this is true when the application’s business rules require many side effects to an update operation, including reading additional database records to validate the data being modified, or reading and writing other records to reflect changes (updating totals or other calculations in other parts of the database, for example). Using the OpenEdge® AppServer moves all of that update logic onto the same machine with the database. This can greatly improve performance compared with using a client/server database connection to return all of the related records to the client for processing.

The SDO is specifically designed to run on a stand-alone client, or transparently divided between the 4GL client and AppServer, or on an AppServer accessed from a non-Progress client. If you follow the guidelines discussed in this guide, as well as in the ADM documentation and course material, your applications will be well positioned to run successfully in a wide variety of deployment environments.

This section outlines the process of running an SDO from the perspective of the RowObject temp-table and its update counterpart, RowObjUpd. This description presumes that the SDO is divided between client and AppServer. If the SDO is running entirely on the client, essentially the same steps occur, but all in a single procedure in a single Progress session.

Note: You do not need to understand all these steps or the procedures that are called before you begin building and using SDOs. However, as you begin to write data validation logic for your SDOs, it will be useful to understand how the data is moved around and the order in which things happen. The TransactionValidate procedures mentioned are internal procedure names to which you can attach validation logic to be executed at various points during the update process. These procedures are discussed in detail in the "Server-side validation" section.